過去在做前端作業時，課程都已經設計好 API ，不需要對所串接的資料格式有太多思考，一切都好像是理所當然。然而當我進入職場與後端有更多的討論後，才發現前後端在實際處理資料時，有著不一樣的思維與需求。

後端偏好使 Key-Value 結構

在後端開發中 Key-Value 結構特別常見，這是因為它能夠快速查找和檢索資料（想了解更多請見下方參考資料的前兩篇），非常適合用在資料庫操作和商業邏輯處理上。例如，後端工程師經常需要快速地從資料庫中提取使用者資料，這時候 JSON 格式的 Key-Value 結構就非常有利：

// JSON 格式的 Key-Value 結構
{
  id: 1,
  name: "Alice",
  email: "alice@example.com"
};

即使在處理更複雜的資料結構時，後端也傾向於使用這種 Key-Value 結構：

// 嵌套的 JSON 格式，展示複雜的 Key-Value 結構
{
  "data": {
    "user": [
      {
        "id": 1,
        "name": "Alice",
        "email": "alice@example.com"
      },
      {
        "id": 2,
        "name": "Bob",
        "email": "bob@example.com"
      }
    ]
  }
}

前端偏好使用陣列（Array）

不過，在前端碰到的情況就不同了，前端更常需要展示資料，使用陣列會讓我們更容易渲染，或是陣列能輕鬆操作 filter 、 reduce 等方法來做資料處理。

// 陣列的資料型別
const users = ["Alice", "Bob", "Charlie"];

在實務上，前端經常需要處理包含多個屬性的資料，比如使用者列表。在這種情況下，物件陣列（Array of Objects）是最合適的，因為它能夠清楚地表示每個使用者的多個屬性，並且可以利用 map 這樣的陣列方法輕鬆地渲染列表：

// 物件陣列的資料型別
const users = [
  { id: 1, name: "Alice", email: "alice@example.com" },
  { id: 2, name: "Bob", email: "bob@example.com" }
];

在了解前後端常處理的資料結構後，有沒有覺得 JSON 作為 API 格式能讓前後端都方便使用，真的是很棒的設計呢～ 那其實 JSON 文件中真的也有提到是建立在無序的「名稱-值」與有序的「列表」之上：

JSON is built on two structures:

• A collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array.
• An ordered list of values. In most languages, this is realized as an array, vector, list, or sequence.

適情況設計具擴展性的資料結構

這邊也想提在設計資料結構時要考量到未來的擴展性。一個現在看來足夠的簡單結構，隨著需求增加，若缺乏彈性設計，後期可能需要重構。例如，最初的 API 回傳格式僅需包含單一項目的資料：

{
  "item": "product1"
}

但隨著需求變多，未來可能需要處理多項目資料，這時候改成陣列結構會更有彈性：

{
  "items": ["product1", "product2", "product3"]
}

因此，在規劃新功能時，最好能與團隊中的不同部門進行討論理解未來可能的需求，以便在一開始就設計出具有足夠彈性的資料結構，減少未來可能的重構成本。

參考資料

• 資料結構筆記：雜湊表、樹與圖
• [Day 12] Key-Value Database: 簡介
• Introducing JSON
• JavaScript Object Notation 精要